"Well it works on MY computer"
If you want to make a (positive) impression on the viewer, the most essential thing is to make sure that the viewer can actually see your production. Here are some points you should keep in mind:
Think before you try
Please add checking for things you use that are not taken for granted, like OpenGL extensions or hardware requirements. That way you can keep people with less-than-state-of-the-art hardware from mocking you. Having an error message stating: "Sorry, but our demo requires vertex shaders and you don't seem to have any" is better than just returning to Windows or having a black screen during the demo. Just make sure that your checks actually work, I know of at least two demos that complain about the lack of multitexturing support on my computer (one of them even suggests that I'm poor because I can't afford a decent GFX card, and it's from 1999). I only have a Geforce2 but I'm quite sure it can do multitexturing, at least when it's my code we're talking about.
This one should be a no-brainer, but apparently it's not: Test your production on multiple computers. If you can't do it before the deadline (which is a bad excuse anyway, finishing a production at the partyplace is stimulating and fun but I don't much appreciate people who say "this sucks but I did it at the party so what do you expect". Why release it at all then?), do it after the deadline and fix the bugs for your final version, or at the latest your next release.
Error messages
One of the more puzzling issues of modern demo coding is the fact that some people do not put in error messages in their productions. I can understand it when we're talking about a 64k or a 4k intro where the size is important, but a demo or a final version of the intro? Nothing is more annoying than getting a black screen or a full-featured Windows crash with no information about the cause or a possible solution. Just because the first version of your demo engine works flawlessly on your computer doesn't mean you shouldn't check for errors.
Also, write your error messages in English. It does the watcher little good if your demo quits with a messagebox that states "przsyf placfz!!1" (no offense meant to Polish people :)).
Configuration dialogs
Please have one. I don't want to watch your demo at 640x480x16bit. Or at 120Hz which my monitor will likely not be able to handle.
DOS
Please, no more DOS. It's 2004. Or if you must, at least make sure it runs under Win2k/XP or many people will not see it. Luckily there hasn't been much DOS stuff anymore, with the exception of my own 4K intro but it was old realmode code and I wanted to get it released :) (pot kettle black...)
ESC
Yes, there actually are productions you can't exit with the Escape key. Usually these are also dreadfully bad in other respects as well, which is a deadly combination. Thank Goddess most demoparties have this in their competition rules.
Screen mode switching
This is a pet peeve of mine. Way too many demos do not restore my desktop to the correct resolution after they've finished. If you are using the old NeHe basecode (as many people seem to do), switch to the new one (or better yet, write your own). Test it on different computers.
Hardware requirements
Modern demos tend to ask a lot for the hardware. This is understandable of course, as the majority of people have fast rocessors and loads of ram, and I have nothing against that. However, take into consideration that many people are still running on Geforce 2-class cards. If you use pixel and vertex shaders to do something really cool like displacement, fire or water effects, go for it. If you use them to do gouraud shading, think if they are really necessary or add an option for the rest of us. I expect this to change in a short while though, when more and more people upgrade their hardware. (and to be honest, I AM a poor student and can't afford a Geforce 4 :)). On the other hand, a good example of brilliant use of shaders is Planet Risk by Andromeda Software Development. If you can make your production look like that, go ahead!
Luckily the Windows age has brought us fairly well-behaving productions. The problematic ones are a minority nowadays and anyone who remembers the UniVBE and GUS days will probably be quite happy about the current situation. Still, I have to admit I can only admire people who manage to make programs that cannot be killed using ctrl+alt+del under Windows NT/2k... :) (maybe someone could write an article on how to do that? It surpasses my skills)
As an example of a demo that's cool but difficult to run, I refer you to the infamous Optic Nerve from Asm'93. I've heard it's really cool. I'm not sure though, as I've never seen it or know anyone who's ever been able to get it to run. You don't want that to happen to your production.
Memory leaks and pointers
The most common / annoying reason of a crash. Your demo is leeching 140mb ram from the system and releasing only 80mb or your pointers are pointing to somewhere illegal. If the program doesn't crash after the exit or during the runtime the system will surely crawl and die after watching few demos doing this. So get yourself a memory manager and start checking your programs memory usage. We've learnt this a hard way as couple of our earlier demos are good examples of this. There shouldn't be a situation where you need to reboot after watching a demo.
Closing: If you think it hard you'll notice that coding demos is not a far way from software engineering in business world. Think about this metaphora: We're software engineers and we provide software for our customers - the sceners. If we're ever going to be a serious company and have success we should keep our customers as happy as possible. This means making software that actually works.